The following abbreviations are herewith defined, at least some of which are referred to within the following description about at least the prior art and/or the present invention.    HLS HTTP Live Streaming    HTTP Hypertext Transfer Protocol    IP Internet Protocol    MPEG Moving Picture Experts Group    MRTG Multi Router Traffic Grapher    RTP Real Time Transport Protocol    RTSP Real Time Streaming Protocol    SNMP Simple Network Management Protocol
Adaptive bitrate streaming is a technique used by an adaptive streaming server for streaming multimedia over one or more networks to user devices (e.g., computers, mobile communication devices, tablets, smart phones). While in the past most video streaming technologies utilized streaming protocols such RTP with RTSP, today's adaptive streaming technologies are mostly based on HTTP and are designed to work efficiently over large distributed HTTP networks such as the Internet.
HTTP adaptive bit rate streaming requires that the adaptive streaming server have multiple files of the content stream (source video, multimedia) which are encoded at different bit rates. The adaptive streaming server then switches between streaming the different encodings of the content file based on requests received from the user's device. The result of the HTTP stream is that the user's device experiences very little buffering and a fast start time so the user has a good experience for both high-end and low-end network connections. Today, there are several HTTP adaptive bit rate streaming technologies that can be used by an adaptive streaming server for streaming multimedia over networks such as the Internet to user devices. For example, Apple's HTTP Live Stream (HLS) m3u8 file system is one such HTTP adaptive bit rate streaming technology where a “manifest” file is created to reference many video segments which are updated in real time to play in a particular order. Other HTTP adaptive bit rate streaming technologies include Adobe's Dynamic stream for Flash, Microsoft's Smooth Streaming etc. . . . .
Referring to FIGS. 1A-1D (PRIOR ART), there several diagrams used to help explain how a traditional system 100 can implement a HTTP adaptive bit rate streaming technology. As shown in FIG. 1A (PRIOR ART), the traditional system 100 includes a content provider 102 (e.g., a broadcast network 102a, CDN/content store 102b), an adaptive streaming encoder/transcoder 104, an adaptive streaming server 106, a network 107 (e.g., IP network 107, CDN network 107), and clients 108. The adaptive streaming server 106 receives a request from a particular client 108a for a source video 110 and then retrieves the source video 110 from the content provider 102 (step 1). In this example, the broadcast network 102a has the requested source video 110 and provides the source video 110 to the adaptive streaming encoder/transcoder 104. The adaptive streaming encoder/transcoder 104 takes the source video 110 and generates multiple files 112a, 112b, 112c and 112d (for example) of the same video and audio content but which are encoded at different bit rates. For example, the adaptive streaming encoder/transcoder 104 can output a 4M bit rate file 112a, a 2M bit rate file 112b, a 1M bit rate file 112c and a 512K bit rate file 112d which are all key framed aligned with one another by PTSs/DTSs 114 (see FIG. 1B (PRIOR ART)). Thus, the 4M bit rate file 112a has a section 116a which contains the same video and audio content as the corresponding sections 116b, 116c and 116d of the 2M bit rate file 112b, the 1M bit rate file 112c and the 512K bit rate file 112d. However, the 4M bit rate file's section 116a has a higher quality than the 2M bit rate file's section 116b which has a higher quality than the 1M bit rate file's section 116c which in turn has a higher quality than the 512K bit rate file's section 116d. 
The adaptive streaming server 106 includes a multicast packet escrow 118 which receives the multiple files 112a, 112b, 112c and 112d and a packet escrow database 120 which stores the multiple files 112a, 112b, 112c and 112d. The adaptive streaming server 106 includes a segmenting unit 122 which functions to segment each of the stored files 112a, 122b, 112c, and 112d into multiple segment files 120a1-n, 120b1-n, 120c1-n, and 120d1-n (see FIG. 1C (PRIOR ART)). The adaptive streaming server 106 includes a segment database 124 which stores the segment files 120a1-n, 120b1-n, 120c1-n, and 120d1-n. Each segment file 120a1-n, 120b1-n, 120c1-n, and 120d1-n contains video and audio packets for a predetermined time duration (e.g., 10 seconds). In this example, the segment files 120a1, 120b1, 120c1, and 120d1 (for example) would be associated with time codes t1-t2 and segment files 120a4, 120b4, 120c4, and 120d4 (for example) would be associated with time codes t4-t5.
The adaptive streaming server 106 has a HTTP server 126 which interfaces with the segment database 124 and creates a master manifest file 128 which includes child manifest files 130a, 130b, 130c and 130d (for example)(see FIG. 1D (PRIOR ART)). Each child manifest file 130a, 130b, 130c and 130d respectively includes references 132a1-n, 132b1-n, 132c1-n, and 132d1-n to each of the segment files 120a1-n, 120b1-n, 120c1-n, and 120d1-n. The HTTP server 126 sends the master manifest file 128 through the network 107 to client 108a (step 2). Thereafter, the client 108a sends a request including one of the child manifest file's reference 132a1 (for example) through the network 107 to the HTTP server 126 (step 3). The HTTP server 126 uses the requested reference 132a1 to retrieve and send the corresponding segment file 120a1 through the network 107 to the client 108a which plays the segment file 120a1 (step 4). The client 108a sends another request identifying one of the child manifest file's reference 132b2 (for example) through the network 107 to the HTTP server 126 (step 3′). The HTTP server 126 uses the requested references 132b2 to retrieve and send the corresponding segment file 120b2 through the network 107 to the client 108a which playbacks the segment file 120b2 (step 4′). The client 108a continues to send requests for specific segment files 120a3-n, 120b3-n, 120c3-n, and 120d3-n (for example) and the HTTP server 126 sends the requested segment files 120a3-n, 120b3-n, 120c3-n, and 120d3-n back to the client 108a which playbacks the received segment files 120a3-n, 120b3-n, 120c3-n, and 120d3-n (steps 3″ and 4″). In this way, the client 108a is able to playback the requested source video 110 while experiencing very little buffering and a fast start time so the user has a good experience for both high-end and low-end network connections.
However, the traditional system 100 by implementing the aforementioned HTTP adaptive bit rate streaming technology will experience a problem in which the entire or a major portion of the bandwidth of the network 107 can effectively be used-up because all of the clients 108 whenever possible will send requests to the adaptive streaming server 106 (and other adaptive streaming servers) to receive the highest quality segment files 120a1-n rather the lower quality segment files 120b1-n, 120c1-n, and 120d1-n. Accordingly, there is a need to address this shortcoming and other shortcomings associated with the traditional system 100. This need and other needs are satisfied by the present invention.